I've been doing a lot of Tcl lately on my job. I really didn't intend to. I keep coming off a some great Tcl advocate every time I mention that Tcl can meet the task. We have a 3 week deadline and I hit the ground running on my hire date.
It's not so much that Tcl could do it any better than Perl, Python, Lisp, Scheme or Lua (a new favorite of mine). But, I know Tcl so much better than many other languages that could do the task, and we really needed to get something working. It is a bit embarrassing though when they ask me how long it would take to AES encode some data I'm pushing around and I just shrug and say "a couple of minutes?".
Hopefully all of this daytime Tcl work will get my ass into gear finishing and releasing EFX 2.0. Who knows?
Permalink | Saturday, May 27 8:02 PM
I stumbled up this paper which talks about "Writing Software Books" and I was struck with an idea...
While I've tried at one time to pursue an AFT feature that would allow for literate programming (produce code or HTML/PDF at will from one document), how about just executing an AFT document? That is, an AFT document could either be published (HTML, PDF, etc) or executed (run code embedded in document). The main difference is that you don't "process" the document (like ctangle in CWEB) as much as you "run" the document... sort of interpreting versus compilation.
Now, that would be interesting... especially if embedded code could manipulate the AFT document itself! Quite an interesting take on EFX 2.0: AFT as a content management platform! ;-)
Permalink | Monday, May 08 3:45 PM
Customer: my wife
Problem: Need to easily back up quicken data files to offsite FTP storage every once in a while.
Constraints: Quicken is run on a windows laptop, so background (unattended) backups not practical. Need to keep at least a few months of backed up quicken revisions on FTP site.
Proposed Solution:
So, let's take a quick look at what is required if done in each in Tcl, Perl or Rebol:
Yes, this is over simplifying (and I know there are other ways to do this in Perl or Tcl), but why do I have to do all of this just to get a customized backup solution to work?
Now, of course I'd still have to learn Rebol...
Permalink | Monday, May 01 10:52 AM
At some point, when you develop software to be used by customers (paying or not), you need to figure out what is important. That is, are you developing this software for a community of developers (with the side effect that it does what the customer needs)? Or, are you trying to solve a customer's problem.
There are non-opensource language implementations and platforms out there. And they are being used. People develop useful things in VB, Allegro Common Lisp, K, etc. You may even fool yourself in thinking that as long as there is an open sourced implementation of the language (or platform) then you are safe from the lock-in scenario. But, when you start using something proprietary, you have to commit.
So, here I am thinking about EFX 2.0 (in particular, Storybot and what I'll call "blog-in-a-box"). Does it really matter that I am developing it in an open source language with open source libraries? Not really. Especially when considering that the end user doesn't care. I am also not currently collaborating with a community of developers.
Here is something interesting I've noticed: The proprietary language implementations seem slicker and sturdier... or maybe just more focused. I've been (re)looking at Rebol and I like what I see: Small footprint (under 1MB!), lots of built in stuff, and a free development and binary distribution. But, its proprietary. So what? Isn't the point of developing "end user products" to give the end user something easy to work with?
Am I fooling myself into thinking that just by using Tcl, Gawk or Ksh that I am making it any easier for the end user? Am I really making something that will be improved upon by developers? Are there that many Tcl, Gawk or Ksh developers out there who will modify, improve and support EFX? Probably not.
All of the open source languages I've been using (Perl, Tcl, Gawk, etc) have packaging issues. Some of these issues are ones of quality and integration (e.g. Tcllib's ftp, pop3 and mime packages use very different semantics). Some of these issues are bundling and installation (ugh, how do I bundle AFT if it needs CPAN stuff, or how much time do I spend reducing the Active State distribution dependency of EFX?).
Now, I am not talking about commercializing EFX or any other software I produce, but I've already limited my open source community cred by using non-trendy languages. There is not a huge Tcl, Gawk or Ksh community interested in hacking EFX. I doubt there would ever be.
A lesson: AFT has been out for around 10 years now. I've got (probably) dozens of users around the web. I know of people who install it for their students, co-workers or departments. I've had under a half-dozen code contributions in those 10 years. My Perl isn't great, so one would expect to see more "fixes" or improvements. Most of the "improvements" I've received has been to the rule files (templates), not the Perl code.
Most people just want it to install easy. They don't seem to care that it is in Perl or (perhaps) whether or not it used an open-source language.
Now, I am sure some of my user base that install AFT through Debian or FreeBSD distributions (apt-get and Ports, respectively) would not have found or bothered to install AFT if it wasn't there, but I do get quite a bit of download traffic at the AFT website.
So, if AFT was bundled as a source file and a single rebol runtime binary (for Solaris, Linux, FreeBSD, Windoze, etc), how many people would refuse to give it a try?
Permalink | Monday, May 01 10:33 AM